Web-based software systems are often complex systems with many inter-twined subsystems. One particular subsystem will not know all the subsystems involved in the user's request/experience. Users of these web-based systems get one version of each particular subsystem working to fulfill the user's request. Those versions of the subsystems are typically specified by the system itself and not by the user of the system. Indeed, in general, a common user would not know how to judge what versions of each subsystem to engage for their web request. However, Testing, Quality Assurance, Development, and other pre-release users routinely need to access highly specific versions of one or more subsystems out of the whole collection of inter-twined subsystems.
Existing solutions for requesting particular versions of web resources at run-time may involve including a version number or other identifier of a particular version into a website address as a sub-domain, folder, or query portion. Though suitable for some applications, these solutions do not meet the needs of all applications and/or settings. For example, backend services or other second-level web services are excluded from such direct run-time version specification. A user cannot easily access a user-facing page of a website and directly specify which version of a backend service to use (e.g., which version of a mail service or of a news ticker service to use). To do so would require multiple versions of the user-facing page that each corresponds to different versions of backend services. For example, if three versions of one particular backend service are specifiable, then three different versions of the user-facing page must be created and individually maintained. A user can then call one of these three user-facing pages to access different versions of the backend service. If a second backend service also has three different versions that are specifiable, then nine versions of the user-facing page must be created and maintained in order access all permutations of the website. As can be readily understood, the burden of creating and maintaining multiple different versions of specifiable user-facing web pages in order to test or access multiple different versions of backend services increases rapidly as the number of variations increases. Further, it is not possible to specify at run-time various versions of additional backend services that exist behind the first layer of backend services.